In certain database applications, aggregates of historical data can be required (e.g., in response to queries on a table (or tables) of a database). For example, a sum of financial data for previous years may be requested on a database table that is partitioned by calendar year. Persistently storing such aggregates of historical data may be an inefficient use of memory in a databases (e.g., in an in-memory database), and can require complex logic to implement. A significant effort may be needed for application developers to modify such logic, thus reducing their flexibility to add new features to a given product. However, if aggregates of historical data are not persistently stored, they would then have to be computed “on the fly” (e.g., when they are requested). Such computing of historical data aggregates on the fly can require loading respective data (e.g., historical partition data) from disk each time a given aggregate (or view including that aggregate) is requested. Such an approach can also be an inefficient use of database resources (e.g., repeated loading of historical partitions from disk).